Columbia Kermit/kermit.zip/newsgroups/misc.19960715-19961006/[e-mail] _Sun Jul 28 20:37:09 1996.msg

Internet Message Format | 2020-01-01 | 10KB

Return-Path: [e-mail]
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id UAA03554 for <[e-mail]>; Sun, 28 Jul 1996 20:37:09 -0400 (EDT)
Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id UAA08395 for kermit.misc@watsun; Sun, 28 Jul 1996 20:37:08 -0400 (EDT)
Path: news.columbia.edu!sol.ctr.columbia.edu!news.uoregon.edu!newsfeed.internetmci.com!news.mathworks.com!news.PBI.net!decwrl!nntp.crl.com!nntp.crl.com!croten
From: [e-mail] (Charles Roten)
Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
Date: 28 Jul 1996 22:39:57 GMT
Organization: Widgets, Inc.
Lines: 160
Message-ID: <[e-mail]>
References: <[e-mail]> <4t63nh$[e-mail]>
    <[e-mail]> <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: crl.com
In-reply-to: [e-mail]'s message of Sun, 28 Jul 1996 19:39:39 GMT
Xref: news.columbia.edu comp.protocols.kermit.misc:5666 comp.dcom.modems:145922

In article <[e-mail]> [e-mail] (Glenn Herteg)
writes:

me> I _can_ set the speed to 38400 .. but max throughput indicates a solid
me> connection at _half_ that speed, 19200.  I _cannot_ seem to access
   >>>[...]
me> BTW, the system is an elderly Sun 386i, ...

glenn> Right there you've probably noted the real culprit.  A Sun 386i
glenn> must be running an extremely old version of SunOS,

No fooling.  How about SunOS 4.0.2 .. which was the _last_ version shipped
with that box ?  There are random rumors of units with a beta version of
4.0.3, but these are as illusive as proof of the afterlife.  8^)    8^)

glenn>                                                    and the tty
glenn> drivers from those days are known to have broken flow-control.  I
glenn> have the same problem in a Sun 3/80 running SunOS 4.1.1_U1; see below.

me> I just tried to download a mail archive of uuencoded stuff with two
me> versions of the above .kermrc file.  Archive size was 2280872 bytes.
me>
me> _With_ 'set dial speed-matching off', I got the following:
me> 1) _Lousy_ average packet sizes, all over the map but rarely at the
me>    practical maximum of 8999 bytes.
me> 2) _Lousy_ throughput .. around 1200 CPS.
me> 3) Premature termination due to multiple timeouts less than a quarter of
me>    the way through the download.
me>
me>> Another problem I get from this combination of C-Kermit, terminal
me>> emulator, and windowing system on my box is the (quite sudden)
me>> interruption of a file transmission with the "too many NAKs" complaint
me>> from C-Kermit.
me>>
me>> Owing to the fact that I am not _sure_ of binary file transmission
me>> accuracy ...
me>
me> In conclusion .. "set dial speed-matching off" makes things WORSE .. a LOT
me> worse.

glenn> What you describe are all symptoms of the same problem I'm seeing,
glenn> which is that Kermit does not cope gracefully (ahem) with broken
glenn> flow control.  I wouldn't mind so much, except that its attempted
glenn> recovery can often result in a corrupted file getting
glenn> transferred -- yep, the right number of bytes in the file at the
glenn> "receiving end, and kermit claims it's done, but a UNIX sum" at
glenn> both ends reveals the file didn't make it across intact.  And this
glenn> is in spite of using Block Check 3 for checksumming packets!  I had
glenn> somebody tell me the chances of this happening were 1 in {large
glenn> number}; but sorry, folks, it happens in a macroscopic percentage
glenn> of the time (half the time, perhaps?) on multi-megabyte files,
glenn> under conditions I'll describe.

glenn> I have a Sun-3/80 running C-Kermit 5A(189), 30 June 93, SunOS 4.1
glenn> (BSD),  with a 9600-baud Telebit QBlazer attached to serial port
glenn> B.  On  this serial line, I have installed a tap such that I can
glenn> direct one side or the other of the conversation to an old dumb
glenn> terminal.  By setting the terminal into "monitor" mode, I can see
glenn> all the control characters going back and forth as well as the
glenn> text -- a handy serial-line debugging tool.

glenn> Normally, I connect to the modem by setting the serial port to 19200
glenn> baud. This lets me take advantage of some buffering in the modem
glenn> when I send stuff, and it generally works just fine.  I can
glenn> download large files from my ISP just fine in this configuration,
glenn> without error; the effective rate is choked by the 9600 baud modem
glenn> connection, so that's all the 3/80 sees, and it can handle that
glenn> rate just fine.  (I've tried a 19200 baud modem, and the poor
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
glenn> 68030-with-two-wait-states in the 3/80 is overloaded at that speed, and
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
glenn> must invoke flow control regularly to choke back the transfer rate.)

I wonder if its really your CPU.  You imply you're using a on-motherboard
serial port, if I read you correctly .. mind you, I'm no expert on Sun 3/80
hardware, so I don't know how many serial ports the motherboard on that
beast could support .. just guessing.

But back when I used My OS's DOS emulator and MS-kermit for commo functions,
I used _serial_ _port_ _A_ _on_ _the_ _motherboard_.  The I/O of which, so
I'm told, was limited by the UART on the motherboard.  Now, I've tried a
9600 BPS Zoom modem on that sucker .. and, no soap.  It seems _totally_
unable to negotiate speeds in excess of 2400 BPS.  Just _forget_ about
19200 bps or 28800 bps.  Probable culprit .. a neolithic UART.

My old box _does_ have an AT bus .. and there are drivers that let UNIX
use it, which I "modload" from /etc/rc.local on boot.  So I picked up the
_internal_ modem I described earlier, with it's _own_ bloody UART, which
fits right into one of the (sadly unpopulated) card slots on said AT bus.
Then, again from /etc/rc.local, I built a second device special file,
/dev/ttym1, just as the 386i list suggested.  I can talk to _that_ port
using my new modem from UNIX, as serial port B, IRQ 3.  Leaving serial
port A, /dev/ttya, without a job.  Not to mention ths DOS emulator.

Under the _present_ arrangement, with the motherboard's serial port
completely bypassed and out of it, I routinely (well, not _quite_
routinely .. 8^) transfer files at an effective 1920 CPS.  And my CPU
loading, as reported by 'perfmeter' and 'perfmon' (yup, my OS is _that_
old 8^), is _nil_.  Too small to see.

glenn> Sometimes I want to turn around and send out such a file to
glenn> another site.  If I forget to think about it and just dial out
glenn> using the same parameters, things will appear to work okay -- for
glenn> awhile.  On the dumb terminal, though, I can see lots of CTRL-S
glenn> and CTRL-Q characters being put out by the modem as it tries to
glenn> cope with the overload of receiving data at 19200 and only being
glenn> able to send at 9600.

glenn> The computer is pretty busy in this mode, so I'll often wander
glenn> away, and  come back to discover the perfmeter has dropped to zero
glenn> load, and kermit isn't doing much.  If I recall correctly, a "
glenn> Timeout" error is displayed in the fullscreen display.  If I allow
glenn> this to go on, it may eventually recover and restart the transfer
glenn> at full speed -- but that's generally after a period where it
glenn> receives stuff and NAKs bunches of packets.  I've learned that if
glenn> the transfer gets into this state but eventually completes, the
glenn> *received  file must* be checksummed for integrity outside of
glenn> Kermit, because the Block Check 3 on the packet level was
glenn> inadequate to ensure a reliable transfer.

I get the same sort of behavior .. with an internal modem, low CPU loading,
and rtc/cts flow control.  You earlier mentioned that the misbehavior was,
you suspected, at the device-driver level.  Perhaps it is independent of
these other issues.

Oh, yes, before I forget .. I've got rts/cts flow control set up in both
C-Kermits, fore-and-aft, in their .kermrc files.  And I've checked both
using "show".  But when I add in "&k3" to the dialin string I feed C-Kermit
on my end, to _force_ my modem to rts/cts flow control, it (again) makes
matters _worse_ .. file transfers screwed up in much the same fashion
except worse, and sooner) as with 'set dial speed-matching off' .. multi-
second periods of lockup in interactive throughput (a minute or more, in
some cases) .. a mess.  _Ignoring_/_not_using_ "&k3" in the dialin string
makes all these pathologies go away.  _HUH_ ?!?!?

glenn> This circumstance raises a design issue for future versions of
glenn> Kermit.  There ought to be a way to perform a separate checksum
glenn> algorithm over the entire file at each end of the transfer, and have
glenn> these secondary checksums compared once the transfer is complete.
glenn> This ought to be automated as part of the protocol, if only under
glenn> control of some new option.  Right now, I cannot trust any large
glenn> transfer without checking manually.

glenn> If somebody (Frank?) is interested in the details, I suppose I
glenn> could set up a transfer in some kind of debug mode and log all the
glenn> activity, if that would help diagnose the problem.  (Obviously,
glenn> the log files would be quite large.)  In particular, I'd like to
glenn> know how the packet checksumming is fooled on such a regular basis.

glenn> The "fix" in my situation is to remember to use a different set of
glenn> options to connect when I want to send files from the 3/80.  I end
glenn> up having a separate line in my ~/.kdd file to set the computer
glenn> port speed to 9600 baud to match the modem's negotiated connection
glenn> speed.  Under these conditions, there are far fewer CTRL-S and
glenn> CTRL-Q characters exchanged, so the computer's broken flow-control
is not driven into its failure mode.

glenn> Glenn Herteg
glenn> [e-mail]